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(57) An event allocation mechanism in a processing 
system which mechanism maintains an event table 
which is really a table of event designations to be 
allocated to different processes upon request where 
the requesting processes assign a particular function 
or "meaning" to the event designation. The mecha- 
nism of the present invention maintains the state of 
such allocated events in the event table and signals 
the related (or "waiting") processes that an event 
has happened so that the particular system central 
Jjl processors assigned to execute those particular pro- 
^cesses may then proceed with their execution. 
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A SPECIAL PURPOSE PROCESSOR FOR OFF-LOADING MANY OPERATING SYSTEM FUNCTIONS IN A 

LARGE DATA PROCESSING SYSTEM 



BACKGROUND OF THE INVENTION 



Field of the Invention 

This invention relates to a special purpose pro- 
cessor and more particularly to such a processor 
for off-loading many operating system functions 
that would otherwise be executed by one or more 
centra) processors in a large data processing sys- 
tem. 



Description of the Prior Art 

Multi-processing systems and a single pro- 
cessing system adapted for multi-programming re- 
quire operating systems for the purpose of sched- 
uling tasks on a particular processor, initiating 
input/output data transfers, handling external inter- 
rupts, and the like. Such operating systems, some- 
times called a master control program (MCP). ac- 
tually consist of many different particular processes 
and subroutines, each of which has a particular 
function. Such particular processes and subroutines 
reside in main memory and currently must be 
executed by the particular central processors when 
a processor or another central processor in a multi- 
processing system requires service, such as when 
it has finished a particular process or task, requires 
an input/output operation or some other service. 

More specifically, among other things, the op- 
erating systems allocate and deallocate events 
where an event may be an external interrupt, I/O 
operation, etc.; implement a set of functions which 
may be performed upon these events; maintain the 
status of processes or tasks running on the system; 
perform task priority computations and schedule 
the execution of tasks by various central proces- 
sors; maintain the system timers, including the 
interval timers; and perform some accounting and 
billing functions. 

Statistical studies indicate that a major portion 
of each processor's time, in a multi-processing 
system, is employed in executing operating system 
functions. From these studies, it is estimated that 
the overhead of such management functions has 
been anywhere between ten percent and fifty per- 
cent and occasionally even higher. Furthermore, a 
goodly portion of the time that the corresponding 
central processor is executing operating system 
functions is employed in establishing process prior- 
ity, performing functions on events (as defined 
above) and initiating input/output operations. If even 



these latter functions could be removed from the 
operating systems, then the through-put of the data 
processing system should be substantially en- 
hanced. 

5 It is then the object of the present invention to 
provide a data processing system having improved 
through-put 

It is another object of the present invention to 
provide an improved data processing system 

io wherein those operating system functions which 
require most of the central processor time are 
removed from the main memory of the system. 

It is still a further object of the present inven- 
tion to provide an improved data processing sys- 

T5 tern having facilities for performing those functions 
that would otherwise be a part of the operating 
systems stored in memory. 



20 SUMMARY OF THE INVENTION 

In order to accomplish the above-identified ob- 
jects, the present invention resides in a special 
purpose processor for a large data processing sys- 

25 tern which special purpose processor performs 
many of the functions of the system operating 
systems that utilize most of the central processor's 
running time when those processors are executing 
routines of the operating systems stored in main 

30 memory. More specifically, the basic functions of 
the special purpose processor are that of process 
or task scheduling and the allocation of events to 
such processes or tasks, which events are re- 
quested by or affect the execution of the individual 

35 tasks. 

Particularly, such a processor maintains a 
queue of ready or available processes linked to- 
gether according to an assigned priority so that any 
central processor may be assigned to the highest 

40 priority task when that processor is not busy ex- 
ecuting some higher priority task. The special pur- 
pose processor also includes a mechanism for 
computing task priorities as new tasks are inserted 
into the queue or removed. 

45 The processor of the present invention also 
maintains an event table which is really a table of 
event designations to be allocated to different pro- 
cesses upon request where the requesting pro- 
cesses (including th MCP) assign a particular 

so function or "meaning 1 * t the event designation. 
The processor of the present invention maintains 
the state of such allocated events in the event table 
and signals relocated ( r "waiting") processes that 
an event has happened s that the particular cen- 
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tral processors assigned to execute those particular 
processes may then proceed with their execution. 

A feature then of the present invention resides 
in a special purpose processor for a large data 
processing system which processor maintains a 
queue of ready processes linked together in the 
order of their assigned priority so that they may be 
executed by the various centra) processors of the 
system as those centra) processor become avail- 
able and also an events allocation mechanism for 
allocating available events to the various processes 
upon request 

BRIEF DESCRIPTION OF THE DRAWINGS 

The above and other objects, advantages and 
features of the present invention will become more 
readily apparent from a review of the following 
specification when taken in conjunction with the 
drawings wherein: 

FIG. 1 is a diagram of the large data pro- 
cessing system employing the present invention; 

RGS. 2A-D are diagrams representing a por- 
tion of memory containing data arranged as push- 
down stacks and also a plurality of display regis- 
ters used to access various elements within the 
stack; 

RG. 3 is a schematic diagram of the special 
purpose processor of the present invention; 

RGS. 4A and B are respectively a schematic 
of the process table and also the four-word format 
for a particular process which four-word blocks are 
stored in the process table; 

RGS. 5A-D are formats of the four words 
representing an event as stored in the event table 
of the present invention; 

RG. 6 is a schematic diagram illustrating the 
inputs to the arithmetic logic unit (ALU) of the 
"processor of the present invention; 

RG. 7 is a schematic diagram illustrating the 
inputs and outputs of the process table of the 
present invention; 

RG. 8 is a schematic diagram of the event 
table support logic; and 

RGS. 9A and B are diagrams illustrating the 
manner in which processes are linked in a queue 
according to priority when waiting to procure an 
event and how processes waiting upon the same 
event to happen are so linked. 



GENERAL DESCRIPTION OF THE INVENTION 

A large data processing system, and in particu- 
lar a multi-processing system, which employs the 
present invention is illustrated in RG. 1. The sys- 
tem includes a plurality of main processing units 10 



and one or more I/O processors 11, each of which 
can communicate with a plurality of memory mod- 
ules 12, by way of memory controller 12a The 
present invention is an addition to th system in 

5 the form of task control processor 13 which also 
communicates with any one of processors 10 by 
way of controller 12a 

While the present invention may be used in a 
conventional system of sequential or von Neumann 

70 type processors, the preferred embodiment of the 
present invention, as described below, is directed 
toward a system of processors designed for the 
execution of block-structured programming lan- 
guages, i.e., nested declarations, which is a natural 

75 form for the expression of complex algorithms. A 
particular processor that was designed to empby 
such block-structured, or nested languages, is de- 
scribed in the Barton et aL U. S. Patents No. 
3,461,434; 3,546.677 and 3,548,384. These patents 

20 describe a stack-oriented data processor where the 
stack mechanism, a first-in last-out mechanism, 
handles the flow of operators and associated pa- 
rameters in a manner which reflects the nested 
-structure of the particular higher level languages 

25 employed. Such languages include ALGOL and 
ALGOL-type languages, such a PL/1, EULER, etc. 
(Cf. f E I. Organick Computer System Organization , 
Academic Press, 1973). 

A system of the type described in the above- 

30 identified Barton patents is oriented around the 
concept of a segmented memory and specially 
treated segments called stacks. The processor 
runs in an expression stack; operators take their 
arguments from the top of the stack arid leave their 

05 results on the top of the stack. The data addressing 
space of the executing program is mapped into the 
stack as well as other stacks (inked to it and data 
segments referenced by the descriptors contained 
in the stack structure. 

40 The addressing environment of the executing 
code stream consists of a set of local addressing 
spaces contained within the stacks. These are 
called activation records or lexical regions and 
each consists of a set of variables addressed by an 

45 index relative to the base of the activation record. 
That is to say, addressing of a given data item is 
by way of an address couple of the form (Lambda, 
Delta) where Lambda is the lexical level of a given 
activation record in the stack and Delta is the offset 

so to the variable from the base of the activation 
record at level Lambda In order to access any 
activation record within a stack, the respective 
records, or lexical regions, are linked together by 
pointers from the base of the topmost activation 

55 record to the lowest level activation record. In the 
above-described Barton patents, addressing is op- 
timized by defining an array of "display" registers 
in the processor which registers are maintained in 
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such a manner that element i in the array contains 
the base of the activation record at the level L 

A data stack as might exist in on of memory 
modules 12 of FIG. 1 is illustrated in FIG. 2A and 
consists of four activation records at lexical levels 
0-3, where the value of the topmost lexical level is 
stored in a lexical level register in a corresponding 
processor. The actual addresses in memory of the 
respective bases of the activation records are 
shown in 2A and these addresses are stored in the 
display registers of the corresponding processor in 
a manner illustrated in FIG. 2B. 

Activation records are created by the execution 
of a procedure entry operator by the processor. 
Thus, for the purposes of illustration. FIG. 2C illus- 
trates that the processor is now working in a dif- 
ferent stack or portion of memory. As a result the 
display registers of a particular processor have had 
to be updated and this update is shown by the new 
contents of the display registers as shown in FIG. 
2D. 

Referring back to FIG. 1, the task control pro- 
cessor 13 is designed to relieve the master control 
program of many of its most time consuming func- 
tions. In the prior art, the respective central proces- 
sors 10 of FIG. 1 would be running various pro- 
grams or processes. That is to say, they would be 
operating in different stacks in memory. If, for 
example, a particular processor executed a branch 
instruction which called for a branch to another 
task, it would notify the master control program 
which would then initiate the required process and 
cause the requesting process to be put in a waiting 
state. When the required process has been fin- 
ished, the master control program would then notify 
the requesting process that the required process 
, was finished and the requesting process would 
then be reactivated. Other examples of master con- 
trol program functions have been discussed above, 
such as handling of external interrupts and initial- 
ization of input/output operations. In addition, the 
master control program in prior art systems would 
handle the scheduling of various tasks for execu- 
tion by the various processors 10 of FIG. 1 accord- 
ing to which processes had the highest priority. 

The task control processor 13 of FIG. 1 is 
illustrated in more detail in FIG. 3. The two princi- 
pal functional elements shown therein are process 
table 21 and event table 3)a. Process table 21 and 
process statistics table 20b contain the information 
as to the status of all tasks or processes scheduled 
to be run on the system of FIG. 1 . In the described 
embodiment of the present invention, there can be 
4 K such tasks or processes running on the system 
at any one point in time. 

The status information of the processes in pro- 
cess table 21 are arranged as a queue or a linked 
list of processes according to the priority of the 



processes involved. During th operation of the 
system of FIG. 1, certain processes may be com- 
pleted and removed from the linked list within 
process table 21 and new processes may be in- 

5 serted. In each case, the task control processor of 
FIG. 3 computes the new priority ratings and rear- 
ranges the linked list In this manner, the highest 
priority process is always ready to be assigned to 
an available processor 10 of FIG. 1 as required. 

to It should be evident from the description thus 
far that the terms "task", "process" and "stack" 
are used synonymously where a stack is a natural 
physical location in main memory and the respec- 
tive tasks or processes are independent of one 

/5 another and occupy the corresponding stack 
space. Similarly, the terms "stack number", "task 
number" and "process number" are used synony- 
mously and are the actual, addresses to process 
table 21 of FIG. 3 of the corresponding process 

zo status information. 

Event table 20a is employed to contain in- 
formation as to the status of various event designa- 
tions called for by processes running on the sys- 
tem. In the described embodiment of the present 

25 invention, there may be a maximum of 512 K such 
events being utilized at any one time. When a 
process being executed by a particular processor 
10 of FIG. 1 requires an event designation, it re- 
quests the allocation of such a designation from the 

30 task control processor of FIG. 3, which then al- 
locates an unallocated event designation to that 
process and sends an event token to be placed in 
main memory on the top of the particular stack 
whose process requested that event designation. 

35 Event table 20a then upgrades the event informa- 
tion to indicate that the event has been allocated. 
The event token is made up of the event address 
to event table 20a and also certain coded bits to 
ensure that one of processors 10 of FIG. 1 does 

40 not accidentally create its own event token. Event 
table 20a is also employed to maintain a linked list 
of various processes requesting a particular event 
that has already been allocated and assigns that 
event to the highest priority process requesting that 

45 event when the event is freed or liberated by its 
owning process. 

As was indicated above, an event designation 
does not specify the particular function for which 
the event was allocated. This is done by the re- 

so questing process. Event table 20a serves the pur- 
pose of maintaining the status of the event e.g., 
whether it is available for allocation, whether ft has 
occurred, what processes are waiting on it, and so 
forth. 

55 Continuing on with a description of FIG. 3, 
support logic 22 is employed to insert information 
fields into event table 20a, statistics table 20b and 
link table 20c as well as to extract fields therefrom 
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as required. Local memory 23 serves as an output 
buffer and also maintains a processor table which 
indicates which processes are currently running on 
the respective processors 10 of FIG. 1. 

Message transmission to the other processors 
of FIG. 1 are by way of memory controller 12a 
from output register 29 of FIG. 3. Messages are 
received from controller 12a by way of input regis- 
ter 25 to message buffer 24. As indicated in FIG. 3. 
the various functional units thus described have 
inputs to arithmetic logic unit module 26 by way of 
arithmetic logic unit input multiplexer 27. Arithmetic 
logic unit module 26 is employed to compute pro- 
cess priorities as described above and also to form 
messages for transmission to the other processors 
of the system. Clock timer 28 supplies real time 
clock values to arithmetic logic module 26 to aid in 
the computation of how long a particular process in 
a wait state has been waiting as compared to the 
maximum amount of time it can wait before its 
execution must be reactivated (as well as statistics, 
and task scheduling algorithms). 

All of the functional units of FIG. 3 are under 
the control of sequence control store 30 and are 
activated by the receipt of an external processor 
request by message buffer 24, where the request 
command is decoded by control store 30. 

When the command received from the external 
processor is either a WAIT or PROCURE com- 
mand, the special purpose processor of the present 
invention responds by transmitting to that proces- 
sor a MOVE-STACK command which causes the 
processor to begin executing a different process 
assigned by the special purpose processor of the 
present invention. This command is stored in local 
memory 23 of FIG. 3 and is transmitted to the 
processor which made the initial request along with 
the process number or stack number of the next 
available process having the highest priority for 
execution as will be more thoroughly described 
below. 

The task control processor of FIG. 3 serves to 
maintain the status of the various processes and 
control the execution of those processes by the 
respective central processors 10 of FIG. 1. A pro- 
cess may be in one of four main states as follows: 
Alive - currently executing on a processor 
Ready - in a suitable state to run when a processor 
becomes available; 

Waiting - cannot be run until some event occurs; 
and 

Selected - A main processor has been instructed to 
move to this process stack and acknowledgment to 
this command has yet to be received by the task 
control processor. 

In addition, the task control processor main- 
tains two further state bits for each process, name- 
ly "scheduled" and "blocked". A scheduled pro- 



cess is one which is included in th scheduling 
mechanism and unscheduled when the process is 
to be removed from that mechanism. The four 
states listed abov apply nly to scheduled pro 

5 cesses. A blocked process is one which will not be 
scheduled for xecution on a processor until such 
time as it becomes "unblocked". 

Process table 21 and statistics table 20b of 
FIG. 3 maintain the following information for each 

io process in the system: the process current state, 
Le., ready waiting, etc.; the process priority; accu- 
mulated processor and ready time; the processors 
to which the process may be assigned; maximum 
permitted processor time; and the class of service 

/s of the process. 

The process class is used to implement a 
resource sharing scheme between different groups 
of processes. The task control processor of FIG. 3 
also maintains system wide statistics on processor 

20 utilization and processor time consumed by pro- 
cesses of different classes. These process at- 
tributes may be set and read by software at any 
time, regardless of whether the process is currently 
under the control of the task control processor. 

26 The task control process or FIG. 3 responds to 
process commands from the respective main pro- 
cessor. A SET-PRIORITY command changes the 
priority of a designated stack to a supplied value. A 
SET-CLASS command sets the statistics class of 

30 the designated stack. A SET-PROCESSOR com- 
mand marks the designated stack as being execut- 
able only on a designated main processor. The 
INSERT command causes the designated stack to 
be included in the scheduling mechanism and the 

35 REMOVE command causes the designated stack 
to be deleted from the scheduling mechanism. The 
above commands are merely examples of the 
types of commands issued to the task control 
processor to control process scheduling and many 

40 other commands are employed but their descrip- 
tion is not required here. 

The various commands described above are 
initiated by the main processors when they decode 
specific instructions in the code stream of the pro- 

45 cess that the respective processor is then execut- 
ing. The same is true of the request for event 
allocation in processing. It will be remembered that 
when a given process or task requires an event to 
be allocated, this can only be communicated to the 

so task control processor by one of the main proces- 
sors executing that process. 

The general nature of an event has been well 
described above. Access to an event is obtained 
by a particular process upon execution of an AL- 

56 LOCATE command which, in return, requests th 
event from the task control processor of FIG. 3. 
Th task control processor then generates an event 
token for an available event selected fr m v nt 
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table 20a, which token is placed on top of the stack 
of th requesting process. Often the communica- 
tions between the task control processor and th 
requesting processor are in terms of these event 
tokens. 

In addition to the ALLOCATE function, other 
functions performed by the task control processor 
in response to a received command, include DEAL* 
LOCATE which causes the designated event to be 
returned to the pool of available events and there 
may be other processes which are either watting 
on or attempting to procure the event in which case 
the requesting processor will be notified. The PRO- 
CURE command results in an attempt to procure a 
designated event on behalf of the process which is 
currently executing on the requesting processor. If 
the event is available, it will be marked as unavail- 
able, the owner will be designated as the stack 
number is currently executing. If the event is un- 
available, the process will be suspended, the base 
priority of the owning process will be adjusted such 
that it is at least as great as the contending pro- 
cess' base priority and the requesting processor 
will be rescheduled. 

The LIBERATE command causes the task con- 
trol processor to pass ownership of the designated 
event to the highest priority process which has 
attempted to procure it If no such process exists, 
the event is marked as available. 

The SIMPLE-WATT command suspends execu- 
tion of the process currently executing on the re- 
questing processor until the designated event has 
happened. 

The MULTIPLE Wait command suspends ex- 
ecution of the process currently executing on the 
requesting processor until either a time limit has 
expired or one of a set of events has happened. 

The CAUSE command will "awaken" all pro- 
cesses which are currently waiting on a designated 
event The event will be marked as happened 
unless either a reset option is used or there is 
some stack performing a particular function upon 
the event, in which case it will be left in the not- 
happened state. If the event is available and has 
contenders, the highest priority contender will be 
given ownership of the event 

The SET command marks the designated 
event as happened without reactivating any pro- 
cess which may be watting on it 

All of the tables of FIG. 3 are initialized when- 
ever a halt-load is performed on the system. After 
that the tables are not reloaded but are modified 
from tim to time depending upon the commands 
the task control processor is executing. 

The assignment of the various processors 10 
of FIG. 1 to the various processes or stacks in 
main m mory depends on the commands sent to 
the respective processors under control of control 



store 30 of FIG. 3 which causes the respective 
processors to begin execution in various desig- 
nated stacks. Thereafter, control store 30 of FIG. 3 
will cause individual processors to be rescheduled 

s (moved to another stack) primarily when that pro- 
cessor has executed a watt-on-event command or 
a procure command as was discussed above. Con- 
trol store 30 of FIG. 3 will also cause a processor 
to move to another stack whenever it determines 

10 that it has been operating in its current stack for 
more than a prescribed time. 

DETAILED DESCRIPTION OF THE INVENTION 

75 

FIG. 4 is a representation of the organization of 
process table 21 of FIG. 3 which is a static RAM 
with a capacity of I6K word locations of 17 bits 
each. This RAM is divided into 4K four-word blocks 

20 so as to provide the information required for the 
scheduling and manipulation of information for 4K 
processes as was described above. Each four-word 
block is addressed by a 12 bit process number, as 
was described above, which is supplied with 2 

25 extra bits to select which of the words is to be 
addressed in the particular four-word block. 

FIG. 4B illustrates the format of one of the four- 
word blocks in FIG. 4A. 

In WORD-0 of FIG. 4B. bit 16 is the selectable 

30 bit which indicates that the process is a candidate 
for selection as head of the ready queue (which is 
described below). The process must be scheduled 
and ready and not blocked to be in this state. Bits 
15-12 identify the statistics class to which class the 

35 current process belongs. Bits 11-0 are the ready 
queue forward link, which is used when chaining 
through the ready queue in order of descending 
priority. That is to say, bits 11-0 are the 12 bit 
process number or address to the process table of 

4tf~~ the next lower priority process in the linked list of 
such processes. 

Word-1 of FIG. 4 is similar to WORD-0 except 
that bits 11-0 now represent the ready queue re- 
verse link or the process number of the next high- 

45 est priority process in the linked list of processes 
scheduled on the system. 

In WORD-2 of FIG. 4B, bit 16, when set in- 
dicates that this process is at the head of the ready 
queue for its particular processor designation as 

so will be described in relation to WORD-3. Bits 15-3 
of WORD-2 are the most significant portion of the 
total priority of the process which priority is setable 
by some processor task and is manipulated by th 
task control processor of the present invention. Bits 

55 8-0 repres nt the least significant portion of the 
total priority of the process and are manipulated by 
the scheduling algorithm employed by the task 
control processor of the present invention. 
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In WORD-3 of FIG. 4B ( bit 16, when set, in- 
dicates whether or- not the current process has 
been scheduled on the system. Bits 15-8 represent 
th original base pri rity of the process. This is the 
lowest base priority which the process would fall 
back to when lock contention conditions are re- 
solved. Bits 7 and 6 indicate the type of processor 
upon which the current process is to be run 
(namely whether the processor is a main processor 
10 of FIG. 1 or I/O processor 11 of FIG. 1, or a 
future processor type not yet implemented). Bits 5 
and 4 represent the process state which may be 
Waiting, Ready, Selected (as was described 
above), and Alive. Bit 3, when set, indicates that 
the process has been "blocked" and task control 
processor will not schedule it for execution on a 
processor. Bit 2. when set indicates that this pro- 
cess is to be interrupted on the next move stack 
command telling a processor to move to this stack 
number. 

Event table 20a of FIG. 3 contains storage 
locations of the status of 512K events. Like process 
table 21 , each storage location in event table 20a is 
made up of a four-word block. The general formats 
of the respective words are illustrated in RGS. 5A- 
D. Each block in the event table is addressed by 
an event number which is part of the event token, 
as was described above, along with two other bits 
which specify which of the four words is to be 
addressed. Each of the four words is 52 bits in 
width. 

FIG. 5A represents the general format of 
WORD-0. As illustrated therein, there are two prin- 
cipal fields that are relevant to this disclosure. Bits 
31-24 indicate the priority of the highest priority 
process which is contending or trying to procure 
this event while K is owned by some other process 
for reasons that were described above. Bits 18-0 
contain the event number of the next lower priority 
event owned by the process which owns the cur- 
rent event That is to say, this field is a forward link 
in a queue of all events currently owned by the 
owner of the current event 

FIG. 5B represents the general format of 
WORD-1 which is similar to that of WORD-0 except 
that bits 18-0 now represent the owner queue re- 
verse link or the event number of the next highest 
priority event owned by the owner of the current 
event 

FIG. 5C generally represents the format of 
WORD-2 which has two fields that are of particular 
interest here. Bits 35-24 contain the number of the 
current owning process. Bits 11-0 also represent a 
process number which represents the highest prior- 
ity process which is attempting to procure owner- 
ship of the current event 

FIG. 5D is a general format of WORD-3. Bit 51 
of this word, when set indicates that the current 



event has been allocated. Bit 50, when set. in- 
dicates that the event is available. Bit 49 is a 
special bit which, when set indicates that owner- 
ship of that event has been obtained by a particular 

s authorized process and taken away from all other 
processes that had had ownership. Bit 48. when 
set indicates that the event has happened or oc- 
curred. Bit 47, when set indicates that there are 
contenders or processes attempting to procure this 

to event Bit 46, when set indicates that there are 
processes waiting for this event to happen. There 
are two other fields or sets of bits which are of 
significance to this disclosure. Bit 19-0 are a point- 
er or link to a list of processes which are waiting 

75 for the event to happen, which list is in link table 
20c of FIG. 3. Bits 12-0 of this link are the process 
number of the first process in the list. 

WORDS 0, 1 and 2. as described above, are 
basically concerned with processes waiting to pro- 

20 cure events while WORD-3 is basically concerned 
with processes which are waiting on events. In 
regard to processes waiting on an event it should 
be emphasized that only one process may own an 
event or a plurality of events, at any one time, 

25 However, a number of processes can be waiting on 
a given event even though they don't own it The 
reason for this is in the nature of the block-struc- 
tured programming languages employed in the 
preferred embodiment of the present invention, as 

30 was discussed above in relation to RGS. 2A-D. 
That is to say, with such block-structured lan- 
guages, any process, although independent, is part 
of a hierarchy of processes. Thus, when a given 
process requests and is allocated an event it noti- 

35 fies its parent process that it owns that event and 
has assigned a function to it and the parent pro- 
cess in turn notifies other sibling processes that the 
particular event has been allocated and assigned a 
function. Any of the sibling processes requiring that 

40 event are then placed in a waiting state until the 
event occurs. 

FIG. 6 is a more detailed schematic diagram of 
arithmetic logic unit module 26 and arithmetic logic 
unit input multiplexer 27 of FIG. 3. In FIG. 6, 

45 arithmetic logic unit module 26 includes arithmetic 
logic unit 40 which receives inputs from B register 
41 and accumulator 42. The output of arithmetic 
logic unit 40 is to rotator 43 which is a shifting 
mechanism that may shift left end around either 

so eight bits or one bit The output of rotator 43 is to 
accumulator 42. The output of B register 41 and 
accumulator 42 are also supplied to output mul- 
tiplexer 44. The input to arithmetic logic unit mod- 
ule 26 is by way of the series of input multiplexers 

55 27a and 27b which together form arithmetic logic 
unit input multiplexer 27 of FIG. 3. The inputs to 
these tw multiplexers were d scribed above in 
regard to FIG. 3. 
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FIG. 7 illustrates the input and output logic for 
process table 21 of FIG. 3. In FIG. 7 t the actual 
process table is process HAM 50 which is a 16K 
by 18 bits (including parity) static random access 
memory. Addresses and data are received from 
arithmetic logic unit module 26 of FIG. 3 with the 
addresses going directly to process RAM input 
multiplexer 51 and the data going directly to the 
input of process RAM 50. Process RAM input mul- 
tiplexer 51 selects either the address from the 
arithmetic logic unit module or from the output of 
process RAM 50 which address is a 12 bit process 
number as was described above. The selected 
address is then sent to address counter 52 for 
addressing process RAM 50. Two bits can also be 
received from sequence control store 30 of FIG. 3 
by word register 53 of FIG. 7. As was explained 
above, these two bits specify which word in a 
particular process word-block is to be selected. 
These two bits may also come from a constant 
which selects the priority word of a particular pro- 
cess block and word select multiplexer 54 selects 
between either the constant or the contents of word 
register 53. These two bits are then added to the 
12 bit output of address counter 12 to create a 14 
bit address to process RAM 50. 

Magnitude comparator 56 serves to compare 
the priority of the current process block being 
addressed in process RAM 50 which a target prior- 
ity as received by target priority register 57 from 
arithmetic logic unit module 26 of FIG. 3. This 
target priority represents the priority of a task to be 
inserted in the linked list of tasks being maintained 
in process RAM 50. 

Selectable task function unit 58 of FIG. 7 
serves to compare the class of each of the pro- 
cesses in process RAM 50 with the contents of 
class enable mask 59 to see which of the current 
processes are enabled for execution on an avail- 
able processor, in which case sequence control 
store 30 of RG. 3 is notified by selectable task 
function 58. Mask control function unit 60 serves to 
set various bits in class enable mask 59 to indicate 
which classes can be run on currently available 
processors. 

RG. 8 illustrates in more detail support logic 22 
of RG. 3 for receiving data for input into and 
fetching data from event table 20a, statistics table 
20b and link table 20c of RG. 3. All data transfers 
into and out of those tables is by way of staging 
register 70 which can receive data from the 
arithmetic logic unit module 26 of RG. 3 or from 
respective tables themselves which are formed of 
dynamic RAMs. Staging register 70 can also re- 
ceive data from its output and these three inputs 
are selected by input select unit 71. The data 
remains in staging register 70' for one clock period 
while its parity or error correction code (ECC) is 



checked by check/generator 74. Th data may then 
have fields extracted from it by field extraction unit 
73 for transmission back to the arithmetic logic unit 
module or the entire output data from staging reg- 

5 ister 70 can be combined with a parity bit from 
check/generator 74 for transmission to the respec- 
tive event table, link table or statistics table. The 
input to field extraction unit 73 is selected by field 
extract input multiplexer 72. 

to Addresses for the respective tables are gen- 
erated by address formation function unit 75 by 
receiving a 20 bit field from field extraction unit 73. 
An 8 bit literal from sequence control store 30 of 
RG. 3 informs address formation function unit 75 of 

75 the particular table to be addressed and formation 
function unit 75 then forms the appropriate address 
for transmission to address counter 76 from which 
it is sent to the respective table by address source 
multiplexer 78 which may also select an address 

20 from refresh address counter 77 when the dynamic 
RAMs of tables 20a. 20b and 20c of FIG. 3 are 
being refreshed. 

RG. 9A is a diagram of how ownership is 
passed from one process to the next lowest pro- 

25 cess waiting to procure an event. As shown therein, 
when an event becomes available having been 
freed by its owning process, the P-head field of 
WORD-2 of the particular event block is used as a 
pointer to link table 20c of RG. 3 where the pro- 

30 cess number of the next lower priority process 
requesting ownership resides. The event is then 
assigned this process as owner and this process is 
then made ready for the next available processor 
10 of RG. 1. When that processor becomes avail- 

35 able, it is given instruction to move to the stack 
number of the now owning process. When the 
event again becomes available, the above proce- 
dure is then repeated. 

RG. 9B illustrates how link table 20c of RG. 3 

40 is employed to link processes waiting on this same 
event As shown therein, when an event has oc- 
curred and its -happened" bit has been set, {due 
to the receipt of a CAUSE command received by 
the task control processor of RG. 3). the W-head of 

45 W0RO3 of the particular event block is employed 
to point both to the particular process block in 
process table 21 and also to the process fink in link 
table 20c and this action ripples through the link 
table and the process table such that all processes 

so waiting on that event are made ready for the next 
available processor 10 of RG. 1. 

One advantage, among others, of the proces- 
sor of the present invention is that external inter- 
rupts now vanish and the device requesting th 

55 interrupt, such as an I/O processor, merely signals 
the special purpose processor of the present inven- 
tion that a specific event has occurred by sending 
a CAUSE command which causes that event to 
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have its status changed to "has occurred*. 



EPILOGUE 

A special purpose processor has been de- 
scribed above'for the purpose of ofHoading those 
operating system functions which consume most of 
the processing time of the various processors in a 
large data processing system. Specifically, the spe- 
cial purpose processor is adapted to schedule pro- 
cesses or tasks on the various processors as the 
processors become available, which processes are 
scheduled according to their assigned priority. The 
special purpose processor also maintains an event 
table which is realty a table of event designations 
to be allocated to different processes upon request 
when the requesting processes (including the op- 
erating system) assign a particular function to that 
event designation. The event table is then used to 
maintain the status of all such allocated events and 
to signal all processes waiting on a particular event 
that the event has happened. 

While but one embodiment of the present in- 
vention has been disclosed, it will be apparent to 
those skilled in the art that variations and modifica- 
tions may be made therein without departing from 
the spirit and the scope of the invention as 
claimed. 



Claims 

1. tri a processing system having at least one 
central processor and at least one memory module 
for storing a plurality of processes to be executed 
by said at least one centra) processor, which pro- 
cesses require different events to occur before 
their execution can be completed, each of such 
events causing the process being executed to be 
placed in a wait state, an event allocation mecha- 
nism comprising event table means to store event 
tokens for designation of events and status in- 
formation about various event tokens including 
whether that event token has been allocated and 
whether that designated event has occurred; input 
means coupled to said at least one central proces- 
sor and to said event table means to receive a 
command to allocate an event token to a process 
currently being executed; output means coupled to 
said event table means and to said at least one 
central processor for transmission of a requested 
event token received from said event table means; 
and control means coupled to said input means, 
output means and event table means to respond to 
said command and to maintain the status of the 
various event tokens including whether they are 
available. 



2. An event allocation mechanism according to 
Claim 1, wherein said control means includes a 
control store for transmission of sets of control 
signals to effect the operation of the vent table 

s means and output means in response to a com- 
mand from said at least one central processor. 

3. An event allocation mechanism according to 
Claim 2, wherein said input means includes a mes- 
sage buffer coupled to said control store to store 

io additional processor commands for transmission by 
said control store. 

4. An event allocation mechanism according to 
Claim 1, wherein said event table means contains a 
linked list of all event tokens that have been al- 
ts located to a particular process. 

5. An event allocation mechanism according to 
Claim 1. wherein said event table means includes a 
link table means for storing a list of ail processes 
having requested each of the particular event to- 

20 kens. 

6. An event allocation mechanism according to 
Clam 1. wherein said event table means includes a 
link table means for storing a list of all processes 
waiting on each of the allocated event tokens. 

25 7. In a processing system having at least one 
central processor and at least one memory module 
for storing a plurality of processes to be executed 
by said at least one central processor, which pro- 
cesses require different events to occur before 

30 their execution can be completed, each of such 
events causing the process being executed to be 
placed in a wait state, an event allocation mecha- 
nism comprising event table means to store event 
tokens for designation of events and status in- 

35 formation about various event tokens including 
whether that event token has been allocated and 
whether that designated event has occurred; input 
means coupled to said at least one central proces- 
sor and to said event table means to receive a 

40 command to allocate an event token to a process 
currently being executed; output means coupled to 
said event table means and to said at least one 
central processor for transmission of a requested 
event token received from said event table means; 

45 and control means coupled to said input means, 
output means and event table means to respond to 
said command and to maintain the status of the 
various event tokens including whether they are 
available, said, control means changing the event 

so status in said event table to event has occurred in 
response to a command received by said input 
means. 

8. An event allocation mechanism according to 
Claim 7, wherein said control means includes a 
55 control store for transmission f sets of control 
signals to effect the operation of the event table 
means and output means in response to a com- 
mand from said at least one central processor. 
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9. An event allocation mechanism according to 
Claim 8, wherein said input means includes a mes- 
sage buffer coupled to said control store to store 
additional processor commands for transmission by 
said control store. 5 

10. An event allocation mechanism according 
to Claim 9. wherein said event table means con- 
tains a linked list of all event tokens that have been 
allocate to a particular process. 

11. An event allocation mechanism according w 
to Claim 10, wherein said event table means in- 
cludes a link table means for storing a list of all 
processes having requested each of the particular 
event tokens. 

12. An event allocation mechanism according 15 
to Claim 1, wherein said event table means in- 
cludes a link table means for storing a list of all 
processes waiting on each of the allocated event 
tokens. 

20 
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